Network Working Group L. Berger 
Request for Comment: 5523 LabN Consulting, LLC 
Category: Experimental April 2009 


OSPFv3-Based Layer 1 VPN Auto-Discovery 
Status of This Memo 


This memo defines an Experimental Protocol for the Internet 
community. It does not specify an Internet standard of any kind. 
Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 


Copyright Notice 


Copyright (c) 2009 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents in effect on the date of 
publication of this document (http://trustee.ietf.org/license-info). 
Please review these documents carefully, as they describe your rights 
and restrictions with respect to this document. 


Abstract 


This document defines an OSPFv3-based (Open Shortest Path First 
version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery 
mechanism. This document parallels the existing OSPF version 2 L1VPN 
auto-discovery mechanism. The notable functional difference is the 
support of IPv6. 
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1. Introduction 


This document defines an OSPFv3-based (Open Shortest Path First 
version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery 
mechanism. This document parallels the existing OSPF version 2 L1VPN 
auto-discovery mechanism. The notable functional difference is the 
support of IPv6. 


1.1. Terminology 


The reader of this document should be familiar with the terms used in 
[RFC4847] and [RFC5251]. The reader of this document should also be 
familiar with [RFC5340], [RFC5329], and [RFC5252]. In particular, 
the following terms: 


L1VPN Layer 1 Virtual Private Network 


CE Customer (edge) network element directly connected to the 
Provider network (terminates one or more links to one or 
more PES); it is also connected to one or more Cs and/or 
other CEs. 


C Customer network element that is not connected to the 
Provider network but is connected to one or more other Cs 
and/or CEs. 
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PE Provider (edge) network element directly connected to one 
or more Customer networks (terminates one or more links to 
one or more CES associated with the same or different 


LIVPNs); it is also connected to one or more Ps and/or 
other PEs. 
P Provider (core) network element that is not directly 


connected to any of Customer networks; P is connected to 
one or more other Ps and/or PEs. 


LSA OSPF Link State Advertisement. 
LSDB Link State Database: a data structure supported by an IGP 
speaker. 
PIT Port Information Table. 
CPL Customer Port Identifier. 
PPI Provider Port Identifier. 
1.2. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


1.3. Overview 
The framework for Layer 1 VPNs is described in [RFC4847]. Basic mode 
operation is further defined in [RFC5251]. [RFC5251] identifies the 
information that is necessary to map customer information (port 
identifiers) to provider information (identifiers). It also states 
that this mapping information may be provided via provisioning or via 
an auto-discovery mechanism. [RFC5252] provides such an auto- 


discovery mechanism using Open Shortest Path First (OSPF) version 2. 
This document provides the same functionality using OSPF version 3 
and adds support for IPv6. 


Figure 1 shows the L1VPN basic service being supported using OSPF- 
based L1IVPN auto-discovery. This figure shows two PE routers 
interconnected over a GMPLS backbone. Each PE is attached to three 
CE devices belonging to three different Layer 1 VPNs. In this 
network, OSPF is used to provide the VPN membership, port mapping, 
and related information required to support basic mode operation. 
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OSPF Auto-Discovery for L1VPNs 


The approach used in this document to provide OSPFv3-based L1VPN 


auto-discovery uses a new type of Link State Advertisement 
which is referred to as an OSPFv3 L1VPN LSA. 
carries information in TLV 


(type, 


length, value) 


(LSA), 


The OSPFv3 LIVPN LSA 
structures. 


An 


LIVPN-specific TLV is defined below to propagate VPN membership and 


port information. 


The OSPFv3 LIVPN LSA may also carry Traffic Engineering 
and [RFC5329]. 


see [RFC3630], 


Berger 


[RFC4203], 


Experimental 


This TLV is referred to as the LIVPN Info TLV. 


(TE) TLVs; 
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2. OSPFv3 LIVPN LSA and Its TLVs 

This section defines the OSPFv3 L1IVPN LSA and its TLVs. 
2.1. OSPFv3 LIVPN LSA 

The format of a OSPFv3 L1IVPN LSA is as follows: 


0 1 2 3 

OF AL, 2) 33: Ae oP GAT OTS A D G PBS Ge Od, 203, Ae 6 “7128.9 OF A. 
FFP rte t eta t rte tar tartar t ett tata tata tata ta tata ta tata tata tatoo tat 
| LS age | LS type | 
FFP rte t rte t arta t ate t arta ta tata tata tata tata tata tata tata tata tata 
| Link State ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+HHH HHHH HHH 
| Advertising Router 
FFP ata t atm t rte tartar HHHH HHHH 
| LS sequence number 
FFP ata t etree ta tartar HHHH ta tata tata ta tatoo tat 
| LS checksum | length | 
FRPP ata t atm tr tartar tartar t arta ta tata tata tata ta tata tata tata tata tata tat 

L1IVPN Info TLV 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
TE Link TLV | 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+—— + 


LS age 
As defined in [RFC5340]. 

LS type 
As defined in [RFC5340]. The U-bit MUST be set to 1, and the S1 
and S2 bits MUST be set to indicate either area or Autonomous 
System (AS) scoping. The LSA Function Code portion of this field 
MUST be set to 14, i.e., the OSPFv3 LIVPN LSA. 

Advertising Router 
As defined in [RFC5340]. 


LS Sequence Number 


As defined in [RFC5340]. 
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LS 


checksum 


As defined in [RFC5340]. 


Length 


As defined in [RFC5340]. 


LIVPN Info TLV 


TE 


Berger 


A single L1VPN Info TLV, as defined in Section 2.2 of [RFC5252] or 
Section 2.2 of this document, MUST be present. If more than one 
L1IVPN Info TLV is present, only the first TLV is processed and the 
others MUST be ignored on receipt. If no LIVPN Info TLV is 
present, the LSA is processed (and flooded) as normal, but the 
LIVPN PIT table MUST NOT be modified in any way. 


Link TLV 


A single TE Link TLV MAY be included in an OSPFv3 L1VPN LSA. When 
an LIVPN IPv4 Info TLV is present, a single TE Link TLV as defined 
in [RFC3630] and [RFC4203] MAY be included. When an LIVPN IPv6 
Info TLV is present, a single TE Link TLV as defined in [RFC5329] 
MAY be included. 
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2.2. L1VPN IPv6 INFO TLV 
The following TLV is introduced: 


Name: L1IVPN IPv6 Info 
Type: 32768 
Length: Variable 


0 1 2 3 
0 L23 Ae 6 T 897 0 2I 4-6 PB. 90 L 23 AO 6 EB 9 OF A 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
L1VPN TLV Type | L1VPN TLV Length | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
L1IVPN Globally Unique Identifier | 


S | 
—4+-4-4-4-4-4-4-4-4-4+-4+-4+-4-4+-4-4+-4-4+-4-4+-4+-4+-4+-4+-4-4-4-4-4-4-4-4 
PE TE Address | 

| 

| 

| 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Link-Local Identifier | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


LIVPN Auto-Discovery Information | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
=| Padding | 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ 
| 
+ 
| 
| 
+ 
| 
| 
| 
| 
+ 
| 
+ 
| 
| 
+ 
| 
+ 
L1VPN TLV Type 

The type of the TLV (see above). 
TLV Length 


The length of the TLV in bytes, excluding the four (4) bytes of 
the TLV header and, if present, the length of the Padding field. 


L1IVPN Globally Unique Identifier 
As defined in [RFC5251]. 

PE TE Address 
This field MUST carry an address that has been advertised by the 
LSA originator per [RFC5329] and is either the Router IPv6 Address 


TLV or Local Interface IPv6 Address link sub-TLV. It will 
typically carry the TE Router Address. 


Berger Experimental [Page 7] 


RFC 5523 OSPV3-Based Layer 1 VPN Auto-Discovery April 2009 


Link-Local Identifier 


This field is used to support unnumbered links. When an 
unnumbered PE TE link is represented, this field MUST contain a 
value advertised by the LSA originator per [RFC5340] in a Router 
LSA. When a numbered link is represented, this field MUST be set 
to zero (0). 


LIVPN Auto-Discovery Information 
As defined in [RFC5251]. 
Padding 


A field of variable length and of sufficient size to ensure that 
the TLV is aligned on a 4-byte boundary. This field is only 
required when the L1VPN Auto-Discovery Information field is not 
4-byte aligned. This field MUST be less than 4 bytes long, and 
MUST NOT be present when the size of LIVPN Auto-Discovery 
Information field is 4-byte aligned. 


3. OSPFv3 LIVPN LSA Advertising and Processing 


PEs advertise local <CPI, PPI> tuples in OSPFv3 LIVPN LSAs containing 
LIVPN Info TLVs. Each PE MUST originate a separate OSPFv3 L1IVPN LSA 
with area or AS flooding scope, based on configuration, for each 
local CE-PE link. The LSA MUST be originated each time a PE restarts 
and every time there is a change in the PIT entry associated with a 
local CE-PE link. The LSA MUST include a single L1VPN Info TLV and 
MAY include a single TE Link TLV. The TE Link TLV carries TE 
attributes of the associated CE-PE link. Note that because CEs are 
outside of the provider TE domain, the attributes of CE-PE links are 
not advertised via normal OSPF-TE procedures as described in 
[RFC5329]. If more than one LIVPN Info TLVs and/or TE Link TLVs are 
found in the LSA, the subsequent TLVs SHOULD be ignored by the 
receiving PEs. 


Every time a PE receives a new, removed, or modified OSPFv3 L1VPN 
LSA, the PE MUST check whether it maintains a PIT associated with the 
L1IVPN specified in the L1VPN Globally Unique Identifier field. If 
this is the case (the appropriate PIT will be found if one or more 
local CE-PE links that belong to the LIVPN are configured), the PE 
SHOULD add, remove, or modify the PIT entry associated with each of 


the advertised CE-PE links accordingly. (An implementation MAY 
choose to not remove or modify the PIT according to local policy or 
management directives.) Thus, in the normal steady-state case, all 


PES associated with a particular LIVPN will have identical local PITs 
for an L1VPN. 
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4. 


Dis 


Backward Compatibility 


Neither the TLV nor the LSA introduced in this document present any 
interoperability issues. Per [RFC5340], and due to the U-bit being 
set, OSPFv3 speakers that do not support the OSPFv3 LIVPN LSA (Ps for 
example) just participate in the LSA’s flooding process but should 
ignore the LSA’s contents. 


Manageability Considerations 


The principal concern in operating an auto-discovery mechanism for an 
LIVPN is that the PE needs to be configured with information about 
which VPNs it supports. This information can be discovered from the 
CEs using some form of membership negotiation, but is more likely to 
be directly configured by the operator as described in [RFC4847], 
[RFC5251], and [RFC5253]. No standardized mechanisms to configure 
this information have been defined, and it is a matter for individual 
implementations with input from operator policy how a PE is told 
which L1IVPNs it supports. It is probable that configuration of this 
information is closely tied to the configuration of CE-facing ports 
on the PE, which in turn causes PITs to be established in the PE. 


Additionally, it may be of value to an operator to view the L1VPN 
membership information that has been learned by a PE. An 
implementation may supply this information through a proprietary 
interface, or may allow it to be inspected through the OSPFv3 MIB 
module [OSPFv3-MIB] or the Traffic Engineering Database MIB 
[TED-MIB]. 


Note that the operation of the control plane has no impact on IP 
network traffic because all of the user data is in Layer 1, while the 
control plane is necessarily out of band in a Data Communications 
Network (DCN). 


1. Coexistence with and Migration from OSPFv2 


It is expected that only a single routing protocol instance will be 
used to operate auto-discovery within an LIVPN at any time. Thus, 
coexistence issues only apply to the migration from OSPFv2 to OSPFv3 
and can be expected to be transient. 


Migration from OSPFv2 to OSPFv3 would be a once-only event for any 
network and would probably depend on the migration of the routing 
protocol used within the network for normal GMPLS procedures. The 
migration process would not be any different from the process used to 
migrate the normal GMPLS routing protocol. The steps to follow are 
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clearly a matter for the operator of the network and are not a matter 
for standardization, but the following sequence is provided to 
illustrate the potential actions: 


1. Assign IPv6 addresses to all control plane and data plane 
resources. 


2. Install and enable OSPFv3 on all controllers. 


3. Use OSPFv3 to advertise IPv4 and IPv6 resource identifiers. 


4. Manually verify the advertised membership and topology information 
from the OSPFv2 and OSPFv3 databases. 


5. Start a maintenance window where data continues to flow, but no 
L1IVPN connections can be changed. 


6. Cut over to the OSPFv3 membership and topology information. 
7. Close the maintenance window. 
8. Turn off OSPFv2. 


9. Remove/disable the IPv4 address for all control plane and data 
plane resources. 


6. Security Considerations 


The approach presented in this document describes how PEs dynamically 
learn LIVPN specific information. Mechanisms to deliver the VPN 
membership information to CEs are explicitly out of scope of this 
document. Therefore, the security issues raised in this document are 
limited to within the OSPF domain. 


This defined approach reuses mechanisms defined in [RFC5340]. 
Therefore, the same security approaches and considerations apply to 
this approach. OSPF provides several security mechanisms that can be 
applied. Specifically, OSPF supports multiple types of 
authentication, limits the frequency of LSA origination and 
acceptance, and provides techniques to avoid and limit the impact of 
database overflow. In cases were end-to-end authentication is 
desired, OSPF’s neighbor-to-neighbor authentication approach can be 
augmented with an approach similar to the experimental extension to 
OSPF, see [RFC2154], which supports the signing and authentication of 
LSAs. 
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7. IANA Considerations 


IANA has assigned an OSPFv3 LSA Function Code as described in Section 


2.1 of this document. IANA has made an assignment in the form: 
Value OSPFv3 LSA type function Type Reference 
14 OSPFv3 L1IVPN LSA [RFC5523] 
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